1
00:00:03.875 --> 00:00:06.455
それでは本日ご紹介できることを嬉しく思います、ええと、
2
00:00:06.675 --> 00:00:09.295
強化された分類のためのVictor Databaseセッションと、
3
00:00:09.515 --> 00:00:11.975
ゲストスピーカーのAlessandro Koyaです。
4
00:00:12.515 --> 00:00:14.215
彼はベクターデータベースについて、
5
00:00:14.395 --> 00:00:15.575
強化された分類のためのものと、
6
00:00:15.675 --> 00:00:16.815
彼らがVISをどのように使って
7
00:00:16.815 --> 00:00:18.735
大規模な文書コレクションを扱っているかについて話します。
8
00:00:19.915 --> 00:00:22.015
ええと、Alessandroはデータドリブンマーケティング
9
00:00:22.015 --> 00:00:23.455
およびAIソリューションの専門家です。
10
00:00:23.795 --> 00:00:26.655
彼はNielsen MediaやVodafoneのような国際企業で
11
00:00:26.655 --> 00:00:28.575
豊富な経験を持っています。
12
00:00:28.845 --> 00:00:30.375
また、ビジネス課題への機械
13
00:00:30.375 --> 00:00:32.375
学習の適用に注力するデータサイエンス
14
00:00:32.575 --> 00:00:33.695
およびプロダクトチームを率いています。
15
00:00:34.365 --> 00:00:35.735
また、ミラノのIULM
16
00:00:35.795 --> 00:00:39.735
UniversityでAIと
17
00:00:39.735 --> 00:00:41.375
データドリブンマーケティングを教えています。
18
00:00:42.495 --> 00:00:44.865
ようこそ、Alessandro。これからはあなたの出番です。
19
00:00:45.275 --> 00:00:47.545
ありがとうございます、Stephen。Stephen、ああ、はい、
20
00:00:47.545 --> 00:00:48.665
ご紹介ありがとうございます。
21
00:00:48.665 --> 00:00:49.745
完璧でした。
22
00:00:50.605 --> 00:00:52.705
それから、皆さん、喉声で申し訳ありません、
23
00:00:52.725 --> 00:00:54.225
今日ちょうど体調を崩してしまって、
24
00:00:54.245 --> 00:00:56.745
まさに今、具合が悪くなっているところです。
25
00:00:57.375 --> 00:01:02.105
では、プレゼンテーションに入りましょう。少々お待ちください。
26
00:01:17.175 --> 00:01:17.525
すみません。
27
00:01:20.645 --> 00:01:22.455
うーん、すみません。
28
00:01:22.555 --> 00:01:24.815
少々お待ちください。ええと、Chromeタブ。
29
00:01:27.695 --> 00:01:28.695
できました。
30
00:01:31.555 --> 00:01:32.775
始められます。見えて
31
00:01:32.775 --> 00:01:33.775
います。ありがとうございます。
32
00:01:33.775 --> 00:01:37.905
わかりました。
33
00:01:38.525 --> 00:01:40.265
ええと、それでは、私についてですが、
34
00:01:40.425 --> 00:01:42.745
ちょうど紹介していただきました、ええ、ありがとうSteven。
35
00:01:43.525 --> 00:01:47.905
そして、ええと、では、私の現在の注力分野についてですが、私たちは、
36
00:01:48.355 --> 00:01:52.745
この直近の、ええと、1年でスタートアップを立ち上げてきました、
37
00:01:52.805 --> 00:01:54.825
ええと、それは、ええと、
38
00:01:55.495 --> 00:01:59.225
政策理解を高め、
39
00:01:59.845 --> 00:02:01.305
そして、ええと、ええと、
40
00:02:01.625 --> 00:02:03.665
公共部門における情報に基づいた意思決定を推進することに焦点を当てています。
41
00:02:04.245 --> 00:02:06.385
私たちと一緒に働いている弁護士がいて、
42
00:02:06.445 --> 00:02:09.305
公共政策や立法に関するあらゆることに
43
00:02:09.305 --> 00:02:11.745
非常に精通しています。
44
00:02:11.925 --> 00:02:13.545
ですので、これらが現在の私たちの注力分野です、
45
00:02:14.045 --> 00:02:15.945
ただし実際には、より汎用的な形で
46
00:02:16.085 --> 00:02:19.425
使用できるプロダクトや
47
00:02:20.445 --> 00:02:23.225
アルゴリズムを作っています。
48
00:02:23.405 --> 00:02:26.905
特に、私たちは皆、ええと、
49
00:02:23.405 --> 00:02:26.905
私たちのバックグラウンドはナレッジソリューションにあります。
50
00:02:27.365 --> 00:02:30.385
ですので現在、いくつかのプロダクトを出しています。
51
00:02:30.685 --> 00:02:34.905
一つはpolicy managerで、これは、ええと、ニュースを、ええと、
52
00:02:34.905 --> 00:02:37.345
トピックや政策領域に従って集約しています。
53
00:02:37.605 --> 00:02:41.225
そしてそれが、私たちが分類を必要とする理由です、ええと、stream scope、
54
00:02:41.335 --> 00:02:45.225
これはリアルタイムの放送、ええと、分析ツールで、
55
00:02:45.575 --> 00:02:49.185
たとえば議会の会期
56
00:02:49.445 --> 00:02:51.265
などからリアルタイムに知識を抽出するために使用できます、
57
00:02:51.605 --> 00:02:53.345
あるいは、ええと、最近のように
57
00:02:53.485 --> 00:02:56.865
EU Commissionの委員候補者向けです。
58
00:02:57.445 --> 00:02:58.705
そして私たちは政策に焦点を当てています。
59
00:02:58.885 --> 00:03:02.805
ですから私たちの資金調達チームには、ええ、先ほど言ったように、弁護士
60
00:03:03.305 --> 00:03:04.525
と、ええと
61
00:03:05.025 --> 00:03:06.165
そして数名の人々が
62
00:03:06.195 --> 00:03:09.045
定量分析に非常に精通しています。
63
00:03:09.195 --> 00:03:12.565
これらのおかげで、私たちは、ええ、AIエージェントを作ろうとしています
64
00:03:12.835 --> 00:03:15.485
それが私たちの、私たちの顧、私たちのクライアント
65
00:03:15.865 --> 00:03:20.565
や顧客に、ええ、その分野で何が、何が、
66
00:03:20.565 --> 00:03:22.325
何が起きているのかを理解するうえで優位性を与えられるようにです。
67
00:03:24.085 --> 00:03:27.345
それで、ええと、私たちが行っていることの、ええ、いくつかの例を
68
00:03:27.345 --> 00:03:28.545
お見せします、ええ、
69
00:03:28.545 --> 00:03:32.025
なぜなら、ええ、私たちがなぜ、非常に、
70
00:03:32.225 --> 00:03:36.105
非常に、ええ、精緻な方法、ええ、
71
00:03:36.425 --> 00:03:38.825
この場合、文書を分類する方法を必要としたのかを理解してほしいからです。
72
00:03:38.965 --> 00:03:43.825
ええ、この稼働中のプロダクトは、ええ、使用されています、ええ、ええ、
73
00:03:44.165 --> 00:03:46.865
ライブストリームを文字起こしし、話者分離し
74
00:03:47.205 --> 00:03:49.705
そして分類するために
75
00:03:49.965 --> 00:03:54.585
また、それらを与えられたEUの政策分野に従って
76
00:03:55.015 --> 00:03:56.065
分類します。
77
00:03:56.295 --> 00:04:00.545
それらはかなり多く、何らかの形で重複することもあります。
78
00:04:01.005 --> 00:04:05.945
ですから私たちのクライアント、ええ、私たちは、私たちのクライアントに
79
00:04:06.745 --> 00:04:09.545
幻覚を起こさないシステムを提供したいと考えました、ええ、
80
00:04:09.565 --> 00:04:14.305
そして、ええ、非常に、ええ、レーザーのような
81
00:04:14.965 --> 00:04:16.185
分類方法が可能なものです。
82
00:04:16.885 --> 00:04:20.265
ええと、おそらく、ウェビナーの最後に、
83
00:04:20.625 --> 00:04:23.625
この、ええ、このインターフェースをライブでお見せすることもできます。
84
00:04:24.775 --> 00:04:28.105
私たちが行っているもう一つのことは、典型的なregスタイルのプロジェクトのようなものです。
85
00:04:28.485 --> 00:04:32.825
しかし、ええ、私たちは、ええ、ですからmeboについて話している間に、
86
00:04:32.825 --> 00:04:36.025
なぜなら私たちのすべてのプロダクトでMeboも使用しているからです。
87
00:04:36.295 --> 00:04:39.545
ragが関わる場合、私たちは、私たちが
88
00:04:39.605 --> 00:04:43.425
グラウンディングを目指していることを考慮しています。つまり、ええ、信頼できる
89
00:04:43.725 --> 00:04:46.025
ええ、応答、マルチモダリティを提供することです。
90
00:04:46.285 --> 00:04:49.825
ですから当然、私たちはあらゆる種類の文書をestし、
91
00:04:50.245 --> 00:04:51.865
そして説明可能性です。
92
00:04:52.165 --> 00:04:56.105
例えば、この、ええと、このuiでは、
93
00:04:56.105 --> 00:04:58.945
私たちが実際に、ええ、私たちのタイプのソリューションにおいて、
94
00:04:59.405 --> 00:05:03.985
思考ステップを、ええ、chain
95
00:05:04.005 --> 00:05:05.665
of thoughtの、ええ、形式で示しているのが分かります。
96
00:05:06.205 --> 00:05:11.105
ですから私たちは実際に、常にユーザーに認識してもらいたいのです
97
00:05:11.245 --> 00:05:14.145
どのような種類のデータを、あなたが、
98
00:05:14.245 --> 00:05:16.305
AIエージェントが使用したのかを
99
00:05:16.485 --> 00:05:19.345
ここにある最終回答を組み立てるために。
100
00:05:20.045 --> 00:05:23.025
そして、ええ、そのため、もちろん、私たちはテキスト、
101
00:05:23.575 --> 00:05:27.545
PDF、動画、今ご覧いただいたように、そして音声ファイルも扱うことができます。
102
00:05:29.485 --> 00:05:32.345
これらすべては、ええ、のため、のため、
103
00:05:33.445 --> 00:05:34.945
ナレッジを管理するためのものです。
104
00:05:35.405 --> 00:05:37.865
ええ、私たちは、ええ、jungleを使用しています、ええ、なぜなら、ええ、
105
00:05:37.865 --> 00:05:41.025
非常に堅牢なシステムで、Pythonで作られており
106
00:05:41.165 --> 00:05:44.385
そして私たちは皆、ええ、全員がPythonのバックグラウンドを持っているからです
107
00:05:45.405 --> 00:05:48.785
そして、ええ、私たちは並列の、ええと、
108
00:05:49.705 --> 00:05:51.185
BUデータベースを使用しています。
109
00:05:51.525 --> 00:05:53.185
ですから私たちにはフックがあります
110
00:05:53.585 --> 00:05:57.685
新しいドキュメントが私たちのjungleバックエンドに追加されるたびに、
111
00:05:58.155 --> 00:06:01.045
それは私たちのMigosバックエンドにも追加されます
112
00:06:01.045 --> 00:06:04.805
なぜなら、Migosをその検索機能のために、
113
00:06:04.865 --> 00:06:06.205
ベクトルデータベースとして使いたいからです。
114
00:06:06.705 --> 00:06:11.085
そして私たちは、ええと、一方で、ええと、jungleを使っています
115
00:06:11.545 --> 00:06:14.485
リレーショナルデータベース全体を保持するために、ええと。
116
00:06:15.105 --> 00:06:17.925
ですから、ええと、すべての、すべての製品には
117
00:06:18.075 --> 00:06:21.925
私たちが作っているものには、こうした共通の特徴があります、
118
00:06:22.105 --> 00:06:25.525
jungleを使ったバックエンドを持っていて、それが何らかの形で
119
00:06:26.645 --> 00:06:27.765
並列化されているという特徴です。
120
00:06:28.745 --> 00:06:31.685
そして実際、これは最初の頃、ええと、
121
00:06:31.685 --> 00:06:34.485
私たちが始めたばかりのときに、私は、
122
00:06:34.585 --> 00:06:36.365
それがすでに作られているのか理解しようとしていました。
123
00:06:36.945 --> 00:06:41.925
そうではありませんでしたが、jungleのプライマリ
124
00:06:42.265 --> 00:06:46.325
キーをMilusのプライマリキーとして使うことは、本当に自然になりました。
125
00:06:46.585 --> 00:06:49.205
そして実際、2つのシステムはとてもうまく連携しており、
126
00:06:49.425 --> 00:06:52.445
私たちはラッパークラスを1つ作っただけで、
127
00:06:52.945 --> 00:06:56.845
それであとはすべてが、ええと、基本的に、ええと、動作しています
128
00:06:57.525 --> 00:06:59.045
シームレスかつ透過的に。
129
00:07:00.625 --> 00:07:05.095
私たちが使っている他の技術は、guard、guardrail、AI、near
130
00:07:05.115 --> 00:07:08.975
for Jです。というのも、私たちはかなり多くのナレッジグラフを使っており、
131
00:07:09.435 --> 00:07:12.495
またmedia wikiも使っています。なぜなら私たちはmedia wikiだからです。
132
00:07:12.595 --> 00:07:14.935
私は、私はWiki mediaの、ええと、メンバーです。
133
00:07:15.555 --> 00:07:19.855
そして、ええと、だから私たちは、何らかの形で、ええと、それは、それを使うのに良い方法だと考えています
134
00:07:19.915 --> 00:07:23.895
ええと、それをセマンティックな方法で使うための。
135
00:07:25.135 --> 00:07:28.305
では、ええと、本題に入りましょう。
136
00:07:29.325 --> 00:07:31.905
つまり、私たちには技術的な課題があります
137
00:07:31.905 --> 00:07:33.185
皆さんが見てきたすべてにおいて。
138
00:07:33.845 --> 00:07:35.745
ええと、私たちは進化する必要があります、ええと、
139
00:07:36.455 --> 00:07:39.945
たとえば基本的な分類、キーワードベースから、
140
00:07:40.445 --> 00:07:45.225
非常に専門用語の多いドメインにおけるセマンティックな理解へ、
141
00:07:45.275 --> 00:07:48.825
専門用語が豊富で、また進化もしているドメインであり、
142
00:07:49.325 --> 00:07:51.425
それらは本当に深く、垂直的です。
143
00:07:51.925 --> 00:07:56.185
ええと、政策について考えると、ええと、毎月、
144
00:07:56.275 --> 00:07:58.585
新しい、ええと、新しい言葉があり、
145
00:07:58.855 --> 00:08:01.465
それらは分類に関連付けられます。
146
00:08:02.005 --> 00:08:05.185
そして、ええと、また、もしあなたが、
147
00:08:06.545 --> 00:08:10.765
考えてみると、ええと、ベクトル空間では、もしあなたが、
148
00:08:10.905 --> 00:08:12.685
ええと、たとえば汎用的な
149
00:08:12.905 --> 00:08:16.045
または一般的な、ええと、埋め込み、ええと、モデルを使うと、
150
00:08:17.105 --> 00:08:21.525
政策のベクトル空間における2つの、ええと、2つの分野
151
00:08:21.625 --> 00:08:25.125
政策エラー、2つの政策分野の
152
00:08:25.655 --> 00:08:28.725
領域は、ベクトル空間では非常に近いです。
153
00:08:29.745 --> 00:08:33.045
そしてまた、私たちにはかなり多くの政策領域があります。
154
00:08:33.665 --> 00:08:36.285
ですから考えてみると、次のスライドの1つでお見せしますが、
155
00:08:36.285 --> 00:08:38.725
それは3つ、2つの
156
00:08:39.365 --> 00:08:42.765
公式な政策領域が、ええと、欧州の
157
00:08:43.275 --> 00:08:46.005
立法制度にあるということです。ええと、わかるように
158
00:08:46.005 --> 00:08:49.165
私たちはどんなゼロショットにも頼ることはできません、
159
00:08:49.545 --> 00:08:51.125
たとえば、分類には。
160
00:08:51.585 --> 00:08:55.685
ですから私たちは、ええと、より良い解決策を設計しなければなりませんでした。
161
00:08:59.195 --> 00:09:00.535
それで、ええと、いくつか、
162
00:09:00.965 --> 00:09:04.495
私たちが受け継いできた従来の文書分類には
163
00:09:04.605 --> 00:09:05.815
良い点がいくつかあります。
164
00:09:06.405 --> 00:09:10.655
歴史的な背景を少し説明すると、覚えておいてほしいのですが、ええと、
165
00:09:10.715 --> 00:09:14.415
ニューラルな、ええと、分類の前には、
166
00:09:14.985 --> 00:09:18.735
前処理、ベクトル化、be words、
167
00:09:19.395 --> 00:09:22.975
pf IDF、つまりスパースな種類の検索、
168
00:09:23.585 --> 00:09:25.175
固有表現認識がありました。
169
00:09:25.315 --> 00:09:27.255
つまり、見に行って、ええと、
170
00:09:27.585 --> 00:09:31.175
どれが企業名で、どれが主要な名前で、
171
00:09:31.395 --> 00:09:36.055
あるいは名前などであるかを確認し、そして手作業による特徴エンジニアリングも行います。
172
00:09:36.675 --> 00:09:40.215
そしてこれらの特徴の上に、通常は常に、
173
00:09:40.795 --> 00:09:42.975
ええと、何らかの分類器が構築されてきました。
174
00:09:42.975 --> 00:09:45.975
それはサポートベクターマシン、ランダムフォレスト、
175
00:09:46.515 --> 00:09:48.095
または他の種類の分類器です。
176
00:09:51.555 --> 00:09:56.005
ここ数年に話を移すと、もちろんそうではありません。
177
00:09:56.105 --> 00:10:00.445
ええと、たとえば LSTM ベースのものをすべて見てみると、
178
00:10:00.905 --> 00:10:04.805
ええと、文書を分類する方法として、
179
00:10:05.585 --> 00:10:07.605
いくつかのアプローチが見られます。
180
00:10:07.785 --> 00:10:09.445
つまり、未知の文書があり、
181
00:10:09.825 --> 00:10:12.765
たとえば32カテゴリからなる
182
00:10:12.985 --> 00:10:17.725
コーパスがあるとすると、この未知の文書を
183
00:10:18.105 --> 00:10:21.565
1つまたは1つのカテゴリ、
184
00:10:22.025 --> 00:10:25.125
最も重要なもの、または重複がある場合には
185
00:10:25.185 --> 00:10:28.485
複数のカテゴリ、カテゴリへ分類し、
186
00:10:28.585 --> 00:10:32.685
さらにこれらのカテゴリからの距離スコアも付けるには、どのような選択肢があるでしょうか。
187
00:10:33.485 --> 00:10:37.425
それで、ええと、1つの選択肢は埋め込みベースの分類を使うことです。
188
00:10:37.805 --> 00:10:41.105
つまり、テキストをベクトルに変換し、
189
00:10:41.275 --> 00:10:45.225
事前学習済みモデルを使って、
190
00:10:46.375 --> 00:10:50.255
学習コーパスのための、カテゴリ OID を計算し、
191
00:10:50.675 --> 00:10:54.215
そして各新規文書について、それが
192
00:10:54.315 --> 00:10:56.695
これらの OID のどれにより近いかを見ます。
193
00:10:57.315 --> 00:11:00.055
しかしこれは、ええと、
194
00:11:00.355 --> 00:11:03.415
汎用の事前学習済みの、ええと、
195
00:11:03.525 --> 00:11:05.455
Open AI の埋め込みモデル、
196
00:11:05.515 --> 00:11:07.935
またはたとえばオープンソースの埋め込みを使うことを意味します。
197
00:11:08.245 --> 00:11:10.735
またそのベース、ええと、
198
00:11:11.755 --> 00:11:14.255
そして私たちは実験的に分かりました。
199
00:11:14.715 --> 00:11:17.015
それで、私も警告しておきたいと思いました。
200
00:11:17.555 --> 00:11:20.015
ええと、これら、ええと、私たちが行ったことはすべて、
201
00:11:20.285 --> 00:11:21.615
本当に実験的なものであり、
202
00:11:22.195 --> 00:11:25.295
実際、ええと、それは私たちの、
203
00:11:25.565 --> 00:11:30.215
私たちのドメインに対して最良の結果を与えてくれたものです。
204
00:11:30.585 --> 00:11:34.575
他のドメインでは、もっと良く機能するかもしれませんし、悪く機能するかもしれません。
205
00:11:34.955 --> 00:11:37.655
それで、ええと、私たちの場合、
206
00:11:37.905 --> 00:11:40.935
この埋め込みベースの分類は、あまり、
207
00:11:40.935 --> 00:11:42.415
あまり良い結果をもたらしませんでした。
208
00:11:42.515 --> 00:11:44.855
通常は入力文から始め、
209
00:11:45.345 --> 00:11:48.215
その埋め込みを確認し、それを
210
00:11:48.215 --> 00:11:50.975
埋め込みモデルに通し、それから、ええと、
211
00:11:51.475 --> 00:11:53.925
どの OID に最も近いかを見ます。
212
00:11:55.055 --> 00:11:59.755
分類のもう一つの方法、ええと、もう一つのアプローチは、
213
00:12:00.415 --> 00:12:02.595
ええと、transformersをファインチューニングすることで可能です。
214
00:12:03.135 --> 00:12:07.035
つまり入力文を、ええと、ええと、encoder onlyの
215
00:12:07.635 --> 00:12:09.355
例えばBERTのようなtransformerに与えます。
216
00:12:09.855 --> 00:12:13.035
そしてその上にclassification headを載せます。
217
00:12:13.545 --> 00:12:15.155
これは通常、Hugging、
218
00:12:15.345 --> 00:12:18.315
Hugging Faceスタイルの分類のようなものです。
219
00:12:18.815 --> 00:12:23.315
ですので、Hugging Faceの、ええと、
220
00:12:24.115 --> 00:12:25.915
transformersライブラリに分類を依頼すると、
221
00:12:26.335 --> 00:12:28.355
通常は私たちに方法を提供してくれます
222
00:12:28.355 --> 00:12:32.035
このclassification headだけをファインチューニングするための
223
00:12:32.495 --> 00:12:36.235
通常は、ええと、fully connected layerを上に載せることで、
224
00:12:36.815 --> 00:12:41.195
BERTの上に、または、そしてそれがファインチューニングされます。
225
00:12:41.855 --> 00:12:43.955
ええと、classification headだけを
226
00:12:43.975 --> 00:12:46.795
あるいはシステム全体をファインチューニングする可能性もあります
227
00:12:47.185 --> 00:12:48.195
BERTまで含めて、
228
00:12:49.095 --> 00:12:52.115
しかしそれでも、大量のラベル付きデータが必要になります。
229
00:12:52.775 --> 00:12:55.915
そして、ええと、これは一種のブラックボックスです。
230
00:12:56.235 --> 00:13:00.635
つまり、BERTがどのように訓練されたのか、私は本当にはわかりません。
231
00:13:01.135 --> 00:13:05.995
ですからおそらく、ええと、それは、ええと、私たちは知りませんでした
232
00:13:06.065 --> 00:13:07.435
何がそこに入っていたのかを。
233
00:13:08.495 --> 00:13:10.875
私たちは、次の可能性へ進みます、
234
00:13:11.695 --> 00:13:14.795
そしてこれはあまり好きではありません。なぜならzero
235
00:13:15.015 --> 00:13:18.915
およびfew shot分類で、GPTやcode
236
00:13:18.935 --> 00:13:21.115
などに巨大なpromptを与えるものだからです。
237
00:13:21.535 --> 00:13:25.835
ええと、そして構造化されたstructure j outを求めます、
238
00:13:26.455 --> 00:13:31.115
可能性、つまり可能なclassesを
239
00:13:31.775 --> 00:13:34.195
列挙として、またはprompt内で与え、
240
00:13:34.695 --> 00:13:36.795
そしてこのpromptを解析します。
241
00:13:37.655 --> 00:13:40.675
ええと、この場合のように、私は長いpromptを与えて
242
00:13:40.775 --> 00:13:43.875
その形式で回答を提供するよう指示します。
243
00:13:44.575 --> 00:13:46.275
そして入力テキストを与えます。
244
00:13:46.855 --> 00:13:50.235
なぜこれが好きではないかというと、完全にブラックボックスだからです。
245
00:13:50.565 --> 00:13:51.995
バイアスのリスクがあります。
246
00:13:52.295 --> 00:13:54.835
そして私たちの場合、32のcategoriesがあります。
247
00:13:55.055 --> 00:13:56.155
そこで私たちはそれをテストしました
248
00:13:56.415 --> 00:13:58.355
そして実際にわかったのは、
249
00:13:58.935 --> 00:14:01.715
train testに分割することで
250
00:14:02.215 --> 00:14:07.195
そしてtest set、私たちのinitial corpus、つまり、
251
00:14:09.615 --> 00:14:14.155
その、その、そのmetrics、つまりmetricsのaccuracyは、
252
00:14:14.535 --> 00:14:17.435
実際には本当に悪かったのです、confusion metricsが。
253
00:14:18.615 --> 00:14:22.755
そこで私たちはhybrid approachを選びました、hybridで
254
00:14:22.755 --> 00:14:23.955
実際にはmiを使用します。
255
00:14:24.895 --> 00:14:29.515
そして、ええと、非常に実験的な形で、ええと、どうにかして両方の
256
00:14:29.735 --> 00:14:31.235
世界の良いところを取り入れました。
257
00:14:32.255 --> 00:14:35.835
ええと、traditional methodsからは、keyboardを使います。
258
00:14:36.175 --> 00:14:37.675
ええと、次のslideで
259
00:14:37.675 --> 00:14:38.755
keyboardが何についてのものかをお見せします。
260
00:14:39.025 --> 00:14:43.835
それは、とても、ええと、とても薄いalgorithmsですが、
261
00:14:43.855 --> 00:14:45.875
algorithmicallyには本当にうまく機能します。
262
00:14:46.415 --> 00:14:47.755
T-F-I-D-Fを取り入れました。
263
00:14:47.935 --> 00:14:50.315
実際、私たちはhybrid searchについて話しています、
264
00:14:50.735 --> 00:14:51.965
そしてKNNを使います。
265
00:14:52.225 --> 00:14:55.205
ほら、これはシンプルで解釈可能な分類器です。
266
00:14:55.985 --> 00:14:59.525
そしてニューラルアプローチからは、埋め込み、BG
267
00:15:00.185 --> 00:15:02.765
BGM threeを採用しました。それが今日話している
268
00:15:02.765 --> 00:15:03.845
埋め込みモデルです。
269
00:15:04.385 --> 00:15:07.925
そして、ええと、ええと、効率的なハイブリッド検索のために
270
00:15:08.225 --> 00:15:10.485
モデルベクトルデータベースmailboxを使用しています。
271
00:15:11.805 --> 00:15:16.305
それで、ええと、私たちは、そのパイプラインを上から見ると、
272
00:15:16.965 --> 00:15:18.545
ええと、テキストを受け取ります。
273
00:15:19.315 --> 00:15:22.945
最初に言語検出があり、それを使って、
274
00:15:23.285 --> 00:15:27.505
ええと、ストップワード除去のためにNLTKの言語を
275
00:15:27.685 --> 00:15:28.945
設定していました。
276
00:15:29.365 --> 00:15:32.345
しかし、これらは非常に一般的な前処理ステップです。
277
00:15:33.745 --> 00:15:38.725
文をkey birdに渡すと、キーワードを抽出します。
278
00:15:39.025 --> 00:15:43.805
つまりkey birdは、BERTを使って、
279
00:15:43.905 --> 00:15:45.445
どれが、その、
280
00:15:45.665 --> 00:15:50.045
与えられたテキストにおいて最も重要なキーワードであるかを判断する特別なアルゴリズムです。
281
00:15:51.025 --> 00:15:54.445
そして、入力テキストの
282
00:15:54.585 --> 00:15:56.045
新しく変換されたバージョンを作成し、
283
00:15:56.505 --> 00:15:59.365
そのバージョンをこのスパースベクトルに渡します。
284
00:15:59.865 --> 00:16:03.165
そして元の、まあストップワードなしのものを渡しますが、
285
00:16:03.345 --> 00:16:05.925
ストップワードありで渡すことも
286
00:16:05.925 --> 00:16:10.245
できたでしょうが、元の文を、ええと、
287
00:16:10.305 --> 00:16:13.565
dense vectorで変換するために渡します。
288
00:16:14.225 --> 00:16:17.765
このアプローチはある意味で、ええと、まず第一に、
289
00:16:17.825 --> 00:16:19.365
最良の結果をもたらし、
290
00:16:19.625 --> 00:16:21.445
一種のハイブリッドでもあります。
291
00:16:22.425 --> 00:16:25.565
ええと、key birthをどのように使っているかを今からお見せします。
292
00:16:25.825 --> 00:16:30.085
ただし、ここではある意味で
293
00:16:30.775 --> 00:16:35.245
私たちが、ええと、本当に、ええと、
294
00:16:35.305 --> 00:16:38.245
TF IDFアルゴリズムによってうまく扱われやすい
295
00:16:38.625 --> 00:16:41.285
新しい文を作っていることを考慮してください。
296
00:16:41.705 --> 00:16:44.405
つまり、ある意味でズルをしていると言えます。
297
00:16:44.665 --> 00:16:49.485
つまり、kf IDFの働きを活用するために
298
00:16:50.025 --> 00:16:51.525
文を拡張しているのです。
299
00:16:52.075 --> 00:16:54.725
つまり、それは、次のように機能します、
300
00:16:54.785 --> 00:16:56.085
term frequencyで機能します。
301
00:16:56.305 --> 00:17:00.965
したがって、私たちはある意味で人工的に、
302
00:17:01.425 --> 00:17:04.685
重視するキーワードのterm frequenciesを膨らませています。
303
00:17:05.265 --> 00:17:09.885
そしてこのようにして、問い合わせるとき、つまりK
304
00:17:09.885 --> 00:17:12.565
and Nの部分に進むと、本当に良い結果が得られました。
305
00:17:12.565 --> 00:17:15.525
なぜなら、これらのアルゴリズムの
306
00:17:15.705 --> 00:17:17.965
spars GIDFバージョンが非常にうまく機能するからです。
307
00:17:18.465 --> 00:17:23.405
そして、ネタバレのように言うと、実際にはfifを取得しています。
308
00:17:23.405 --> 00:17:26.045
50%の重みをdense vectorに与えており、
309
00:17:26.475 --> 00:17:29.765
それがもちろん文全体の意味を与えてくれます。
310
00:17:30.305 --> 00:17:34.085
そして50%をT-F-I-D-Fにしています。この場合それを使うのは、
311
00:17:34.085 --> 00:17:36.005
非常に、
312
00:17:36.105 --> 00:17:39.645
このようなドメイン固有の、ええと、専門用語
313
00:17:39.745 --> 00:17:44.725
や言語では、それでもキーワードを使いたいと確信しているからです。
314
00:17:44.875 --> 00:17:47.765
なぜなら政治におけるキーワード、
315
00:17:47.945 --> 00:17:52.085
法律制定における、委員会の名前におけるキーワードは、
316
00:17:52.145 --> 00:17:54.725
たとえば、それらは本当に重要な名前です。
317
00:17:54.985 --> 00:17:59.605
私たちは単に、ええと、文書を取得して、
318
00:18:00.225 --> 00:18:03.845
意味だけに基づいて分類することはできません。
319
00:18:04.665 --> 00:18:06.325
それでもある程度の意味は保持したいのですが、
320
00:18:06.425 --> 00:18:10.325
同時に、これは価値を強調する方法なのです
321
00:18:10.585 --> 00:18:14.245
特定のキーワード、つまり
322
00:18:14.265 --> 00:18:15.485
私たちのドメインに属するものの価値を。
323
00:18:17.145 --> 00:18:20.925
では、keyword keyboard とは何かというと、これは、とても、ええと、
324
00:18:21.285 --> 00:18:24.085
テキストから、ええと、
325
00:18:24.165 --> 00:18:26.325
キーワードを抽出する非常にわかりやすい手法です。
326
00:18:26.905 --> 00:18:30.325
そして実際には、ええと、それは抽出します、
327
00:18:31.665 --> 00:18:35.325
全体の文書に対して、単語埋め込みにおける
328
00:18:35.905 --> 00:18:39.965
コサイン距離が、ええと、最も高い
329
00:18:40.065 --> 00:18:41.205
単語を抽出します。
330
00:18:41.355 --> 00:18:44.405
埋め込みというのは、それが単語を抽出するという意味です
331
00:18:44.435 --> 00:18:47.085
それらが含まれている文書を
332
00:18:47.505 --> 00:18:49.765
最も代表している単語を。
333
00:18:50.305 --> 00:18:51.365
そしてそれらがキーワードです。
334
00:18:51.825 --> 00:18:55.965
ですからこれは、ええと、先ほど言ったように非常にわかりやすく、
335
00:18:56.225 --> 00:18:57.685
そして、ええと、
336
00:18:58.465 --> 00:19:00.525
ダウンロードすることができて、
337
00:19:00.665 --> 00:19:01.925
とてもうまく機能しますし、
338
00:19:02.225 --> 00:19:04.765
私たちの実験では常に、
339
00:19:05.025 --> 00:19:08.205
非常に高品質なキーワードを出してくれます。
340
00:19:09.845 --> 00:19:13.385
では、keyboard が実際に動いているところをお見せすると、これが、
341
00:19:13.455 --> 00:19:16.145
私が最初にお見せしたシステム、
342
00:19:16.175 --> 00:19:17.705
stream scope の発言の一部です。
343
00:19:18.245 --> 00:19:21.545
これは委員候補が、ええと、11月の初めに
344
00:19:21.545 --> 00:19:23.025
話していたものです。
345
00:19:23.645 --> 00:19:28.425
この委員候補は、ええと、担当候補で、
346
00:19:28.805 --> 00:19:29.905
ええと、気候担当です。
347
00:19:30.485 --> 00:19:34.345
もちろん、彼は気候について話していました。そしてこれは、
348
00:19:35.115 --> 00:19:38.145
Bert で処理した後の出力、
349
00:19:38.205 --> 00:19:39.425
Bert の出力です。
350
00:19:39.965 --> 00:19:44.515
ですから、最も重要なキーワードは climate proposal
351
00:19:44.615 --> 00:19:46.955
2015 emission proposal です。
352
00:19:47.335 --> 00:19:50.835
そしてこれは、つまり、ご覧のとおり機能していて、
353
00:19:51.055 --> 00:19:53.795
キーワード抽出にはかなりうまく機能しています。
354
00:19:54.435 --> 00:19:58.845
ただ一つ注意点として、私たちは bird のバージョンを、ええと、
355
00:19:59.185 --> 00:20:01.325
立法文書に合わせて見つけました。
356
00:20:01.595 --> 00:20:06.085
なぜなら、いずれにせよ、それは教師なしの種類の訓練だからです。
357
00:20:06.705 --> 00:20:09.645
そこで私たちは、欧州委員会や
358
00:20:10.265 --> 00:20:12.445
欧州議会の人々によってタグ付けされた
359
00:20:12.445 --> 00:20:15.285
立法テキストを持っていました。しかも非常によくタグ付けされていました
360
00:20:15.285 --> 00:20:18.485
というのも私たちは、ええと、いくつか、ええと、
361
00:20:18.865 --> 00:20:20.565
もちろんデータ可視化も行ったからです。
362
00:20:20.665 --> 00:20:22.365
そして、私たちは、ええと、
363
00:20:22.365 --> 00:20:25.405
クラスターが互いにかなり離れているのを確認しました。
364
00:20:26.305 --> 00:20:29.965
そして、ええと、私たちは、ええと、ファインチューニングを行いました
365
00:20:30.545 --> 00:20:33.525
bird format language modeling の。
366
00:20:33.915 --> 00:20:37.045
それは一種の、ええと、その、一種の、ええと、
367
00:20:37.295 --> 00:20:40.965
ダウンストリームタスク、すみません、訓練目的であり、そこで
368
00:20:41.495 --> 00:20:44.445
文の中から単語が削除されます。
369
00:20:44.825 --> 00:20:48.205
そしてそれは実際に、Bert が学習された2つの、ええと、2つの目的のうちの1つです
370
00:20:48.675 --> 00:20:50.445
Bert が学習された目的です。
371
00:20:50.945 --> 00:20:54.445
ですから私たちは、本当に、Bert の中核を
372
00:20:55.065 --> 00:20:56.405
このような形でファインチューニングしました。
373
00:20:56.985 --> 00:21:00.205
そして key Bert は Bert を使用しているので、
374
00:21:00.875 --> 00:21:05.285
これにより、ええと、新しい、
375
00:21:05.745 --> 00:21:07.965
ええと、出てくる新しいキーワードを使用する可能性が得られました。
376
00:21:08.185 --> 00:21:11.725
つまり、最近の文書がある場合、私たちは
377
00:21:11.725 --> 00:21:13.885
Bert がそれらの単語を知っていることがわかります。
378
00:21:14.465 --> 00:21:18.005
そして、ある単語が本当に重要である場合、もちろん、
379
00:21:18.005 --> 00:21:20.205
Bert がそれらを文脈の中で見たからであり、
380
00:21:20.625 --> 00:21:25.245
そのため、それは、それに、良い、
381
00:21:25.765 --> 00:21:28.485
私たちの目的にとって良い意味を、ええと、与えました。
382
00:21:28.905 --> 00:21:31.245
ですから、ええと、Bert は、
383
00:21:31.545 --> 00:21:34.845
このファインチューニングを行えば、常に更新され
384
00:21:35.225 --> 00:21:38.245
また非常に重要なキーワードも抽出されることがわかります。
385
00:21:38.865 --> 00:21:42.365
したがって、keyword、keyword の結果は、ええと、
386
00:21:42.725 --> 00:21:45.445
キーワードに加えて、各単語の文書全体からのコサイン距離です。
387
00:21:45.725 --> 00:21:46.885
各単語についてです。
388
00:21:50.875 --> 00:21:54.765
では、ええと、
389
00:21:54.865 --> 00:21:56.445
私たちがどのようにそれを行ったかに進みましょう。
390
00:21:56.445 --> 00:21:57.925
これを実際に動かすような形です。
391
00:21:58.505 --> 00:22:01.365
先ほど言ったように、EU には32、ええと、3、
392
00:22:01.385 --> 00:22:03.245
2つのカテゴリがあります。
393
00:22:03.785 --> 00:22:07.365
そして、ええと、政策分野であり、それらはかなり変化しています。
394
00:22:07.675 --> 00:22:11.725
つまり毎月、新しい頭字語、新しい名称があり
395
00:22:11.955 --> 00:22:16.085
それらが、ええと、その中に入り、現れます
396
00:22:17.405 --> 00:22:18.465
会話の中に。
397
00:22:18.885 --> 00:22:22.665
そのため、私たちは、更新され続けるような
398
00:22:23.175 --> 00:22:24.745
システムを作りたいと考えました。
399
00:22:27.695 --> 00:22:31.195
反復的な方法で、どのようにシステムを学習させたのでしょうか?
400
00:22:31.975 --> 00:22:34.795
まず、前のスライドのすべての文書を
401
00:22:35.755 --> 00:22:36.895
取得します。
402
00:22:36.955 --> 00:22:38.455
つまり、32のトピック領域があり、
403
00:22:38.595 --> 00:22:41.015
それぞれのトピック領域に属するかなり多くの文書があります。
404
00:22:41.015 --> 00:22:42.255
それぞれのトピック領域に属するものです。
405
00:22:43.075 --> 00:22:47.615
それらの文書で key bird と一緒に使うために、bird をファインチューニングします
406
00:22:47.955 --> 00:22:50.855
ええと、それらの文書について、ええと、
407
00:22:50.855 --> 00:22:54.695
それらは uk から、European Parliament からの公式なものです。
408
00:22:55.285 --> 00:22:59.175
次に、いくつかの前処理を行います。ええと、例えば、ええと、
409
00:22:59.815 --> 00:23:02.655
一部の文書には複数のタグがある可能性があることを考慮して、
410
00:23:03.075 --> 00:23:05.615
単一のタグを持つものだけを残します。
411
00:23:06.035 --> 00:23:07.855
そして、ええと、そのため一部はスキップします。
412
00:23:08.635 --> 00:23:11.735
そして keyboard を通じて、trans、
413
00:23:12.055 --> 00:23:14.015
変換された文書を作成します。それは
414
00:23:14.115 --> 00:23:17.255
keyboard によって見つかった最も重要なキーワードを繰り返すことによって作られます。
415
00:23:17.955 --> 00:23:20.975
例えば、私が先ほどお見せしたセグメントは
416
00:23:20.975 --> 00:23:22.375
以前はこうなっていましたが、
417
00:23:22.795 --> 00:23:26.655
これは、ええと、末尾が切られており、途中で省略されていますが、
418
00:23:27.115 --> 00:23:29.335
このようなものになりました。
419
00:23:29.955 --> 00:23:34.775
つまり、ここでは私たちがある意味で、ええと、その、
420
00:23:34.875 --> 00:23:39.335
次のTF-IDFシステムが、より重要性を与える際に
421
00:23:39.715 --> 00:23:42.695
つまり、意味的に
422
00:23:43.285 --> 00:23:44.855
より重要だとわかっているキーワードにです。
423
00:23:45.545 --> 00:23:48.165
つまり基本的には、私たちはT-F-I-D-Fを
424
00:23:48.585 --> 00:23:50.645
ある意味カウンターとして使っています。
425
00:23:50.795 --> 00:23:53.805
なぜなら、すでにかなり多くの意味を抽出しているからです。
426
00:23:54.425 --> 00:23:58.085
しかしすばらしい点は、ええと、vuesの、ええと、
427
00:23:58.105 --> 00:24:01.485
ハイブリッド検索システムを通じて、こうした種類の
428
00:24:01.485 --> 00:24:05.205
前処理済みドキュメントを渡すと、そのまま標準の
429
00:24:05.205 --> 00:24:07.005
VUSを使えるということです。
430
00:24:07.225 --> 00:24:10.845
つまり、denseに50%の重み、
431
00:24:10.945 --> 00:24:15.245
そして、ええと、SPS embeddingsに50%の重みでハイブリッド検索を使えます。
432
00:24:15.785 --> 00:24:18.565
そしてBG M threeを適用し、
433
00:24:18.945 --> 00:24:22.885
学習済みドキュメントをVUSの特別な
434
00:24:23.565 --> 00:24:27.405
トレーニングコレクションに挿入します。これは実際に、ええと、
435
00:24:27.755 --> 00:24:31.445
継続的に追加していて、ええと、15日ごとに行っています。
436
00:24:31.465 --> 00:24:34.005
最後のドキュメントを取得するプロセスがあります。
437
00:24:34.585 --> 00:24:38.485
そしてここで反復することで、最終的に
438
00:24:38.635 --> 00:24:40.605
これらのドキュメントを変換するために
439
00:24:41.225 --> 00:24:44.645
使用しているこれらのBertが、
440
00:24:45.475 --> 00:24:49.565
実際にこれらの新しいトークンの意味を理解しているとわかるのです。
441
00:24:50.125 --> 00:24:52.885
つまり、Bertがworkpiece tokenizationを使っているとしてもです。
442
00:24:53.145 --> 00:24:55.405
ですから略語は、問題にはなりません。
443
00:24:55.985 --> 00:25:00.605
ええと、Bertについては、ええと、実験的に
444
00:25:00.795 --> 00:25:02.005
それが重要だとわかりました。
445
00:25:02.115 --> 00:25:06.325
なぜなら、それらのトークンは、
446
00:25:08.935 --> 00:25:13.145
通常のembedding embeddingsのように、そのコンテキストに囲まれていて、
447
00:25:13.245 --> 00:25:16.905
実際にファインチューニングによって、
448
00:25:17.205 --> 00:25:19.865
それらにふさわしい意味を与えるからです。
449
00:25:20.245 --> 00:25:24.825
そして、以前お見せしたBertのプロセスでは、
450
00:25:24.825 --> 00:25:29.745
それらはある種、後で行う
451
00:25:30.815 --> 00:25:34.585
特別なT-F-I-D-F処理のために強化されています。
452
00:25:35.445 --> 00:25:37.215
これは、トレーニングシステム向けです。
453
00:25:37.475 --> 00:25:39.495
そのため最終的には、トレーニングコレクションが得られ、
454
00:25:39.495 --> 00:25:42.735
すべてのドキュメントにこれら2種類の、ええと、
455
00:25:42.915 --> 00:25:47.295
つまり変換済みドキュメントのAPAR vectorと、元のドキュメントの
456
00:25:47.405 --> 00:25:48.975
advanced vectorが含まれます。
457
00:25:49.785 --> 00:25:52.285
では、未知のドキュメントをどのように分類するのでしょうか?
458
00:25:52.825 --> 00:25:55.485
以前とまったく同じことを行います。
459
00:25:55.665 --> 00:26:00.645
つまり、キーワード、fine keywordを使って、そのドキュメントから最良の、
460
00:26:00.785 --> 00:26:02.765
ええと、キーワードを取り出します。
461
00:26:03.585 --> 00:26:06.005
ええと、BGM M threeを適用し、
462
00:26:06.865 --> 00:26:08.725
以前示したのと同じ方法で行います。
463
00:26:08.825 --> 00:26:11.445
つまり、元のものにはdense vectorがあり、
464
00:26:12.205 --> 00:26:14.805
変換済みドキュメントにはsparse vectorがあります。
465
00:26:15.745 --> 00:26:18.005
ええと、特別なAPI endpointがあります。
466
00:26:18.035 --> 00:26:20.725
もちろん、これはproduction serverでは行わないためです。
467
00:26:20.785 --> 00:26:24.245
GPU serverがあり、embed endpointがあって、
468
00:26:24.275 --> 00:26:27.405
これらの、これらのmodelをホストしています。
469
00:26:28.145 --> 00:26:31.845
そして、最も近いkey個の
470
00:26:32.605 --> 00:26:36.525
ドキュメントを、vanilla normal likeを使って取得します。
471
00:26:36.945 --> 00:26:38.125
BU ハイブリッド検索。
472
00:26:38.945 --> 00:26:43.085
そして、ええと、それらは、ええと、距離の順に
473
00:26:43.385 --> 00:26:47.925
取得されるので、ええと、近いドキュメント、近いと
474
00:26:47.925 --> 00:26:50.965
判定されたドキュメントは、より近いものが、
475
00:26:51.025 --> 00:26:54.045
dense の、ええと、ええと、世界の両方で
476
00:26:54.465 --> 00:26:58.125
そして spark の世界でも、もちろん、
477
00:26:58.625 --> 00:27:02.005
最初に取得されますし、それらは、より大きな影響力を持つはずです。
478
00:27:03.145 --> 00:27:06.485
そして私たちは一種の投票を行います、ええと、
479
00:27:06.485 --> 00:27:10.405
類似度スコアが各
480
00:27:10.425 --> 00:27:11.845
訓練ドキュメントの投票力を決定するようなものです。
481
00:27:12.265 --> 00:27:15.765
そして各ドキュメントは実際には自分自身のカテゴリに投票しています。
482
00:27:16.455 --> 00:27:20.075
ですので、最後には一種の重み付き
483
00:27:20.595 --> 00:27:21.915
KNN と呼べるものになります。
484
00:27:22.455 --> 00:27:25.755
そこで各カテゴリの重み付き投票を合計し、
485
00:27:26.055 --> 00:27:27.235
最も高い合計重みを持つ
486
00:27:27.235 --> 00:27:29.275
カテゴリを選びます。
487
00:27:29.855 --> 00:27:31.395
そしてこれは例です。
488
00:27:31.575 --> 00:27:34.275
もし K が 5 に等しく、
489
00:27:34.615 --> 00:27:38.115
そして、これらが最初の 5 つのドキュメントだと分かり、
490
00:27:38.255 --> 00:27:42.355
そして、ええと、もちろんそれらにはラベルが付いていたので、このような類似度がある場合、
491
00:27:42.495 --> 00:27:45.235
私たちは
492
00:27:45.955 --> 00:27:48.595
カテゴリ A が最終的に重み
493
00:27:48.595 --> 00:27:53.195
2 69 で、重み 1 65 のカテゴリ B に勝つことを知っています。
494
00:27:54.615 --> 00:27:58.995
そして、これがこの、ええと、このウェビナーの KNN 部分です。
495
00:27:59.935 --> 00:28:03.875
ええと、そしてこれらは非常に良い結果をもたらしました。
496
00:28:04.375 --> 00:28:09.275
ええと、実際にどのようにベンチマークしたかをお見せします、y で、ええと、
497
00:28:10.015 --> 00:28:13.635
別の、ええと、疑問としては、なぜ BGM three なのか
498
00:28:14.595 --> 00:28:16.075
ということがあり得ます。実際の実験結果です。
499
00:28:16.375 --> 00:28:18.715
そして、ええと、この記事は Medium で見つけることができます。
500
00:28:19.295 --> 00:28:21.355
ええと、まず第一に、それは多言語対応であり、
501
00:28:21.535 --> 00:28:23.475
多言語対応であることは、ええと、
502
00:28:23.815 --> 00:28:25.995
そしてなぜそれが多言語なのか。
503
00:28:26.145 --> 00:28:28.235
ほとんどの言語で本当に優れています。
504
00:28:28.745 --> 00:28:32.075
実際には mIRACL super rank において上回っており、
505
00:28:32.075 --> 00:28:35.955
これは、ええと、
506
00:28:36.235 --> 00:28:40.435
モデルが最も関連性の高い結果を取得するのにどれほど優れているかを示す指標です。
507
00:28:41.135 --> 00:28:45.235
それはほとんどの商用の、ええと、embeddings を上回っています。
508
00:28:45.375 --> 00:28:48.635
つまり OpenAI たとえば、これらは 2 つの OpenAI のものです。
509
00:28:49.055 --> 00:28:53.235
そして実際には精度の平均、
510
00:28:53.495 --> 00:28:55.675
または正しい
511
00:28:56.355 --> 00:29:00.475
ドキュメントを取得する際の平均は、b GM three においてすべての言語で、
512
00:29:00.895 --> 00:29:01.995
他のすべての選択肢を上回っています。
513
00:29:02.265 --> 00:29:04.035
これが私たちが B GM three を使う理由です。
514
00:29:04.215 --> 00:29:06.955
また、それが vus に組み込まれていたからでもあり、
515
00:29:06.955 --> 00:29:10.675
実際、私たちは mi mi の上に多くのものを構築してきたので、
516
00:29:10.815 --> 00:29:13.195
それを使うのは私たちにとって自然なことでした。
517
00:29:15.285 --> 00:29:18.665
ええと、最後に、これらをどのようにベンチマークしたか。
518
00:29:19.175 --> 00:29:20.585
これは正確な科学ではありません。
519
00:29:21.185 --> 00:29:25.585
つまり、ええと、これは作られました、ええと、ええと、つまり私たちはコーダーです。
520
00:29:25.885 --> 00:29:29.705
私たちは、ええと、私たちは物事を
521
00:29:29.735 --> 00:29:33.865
実際に私たちや私たちの特定のドメインにとってうまく機能するように行います。
522
00:29:33.865 --> 00:29:36.345
私たちのやり方で、とてもうまく機能しました。
523
00:29:36.645 --> 00:29:39.905
つまり基本的に、私たちは分割し、トレーニングデータセットを分割して
524
00:29:40.415 --> 00:29:42.245
トレーニングセットと検証セットに分け、
525
00:29:42.465 --> 00:29:44.805
それから、混同行列を確認しました
526
00:29:45.225 --> 00:29:49.685
そして実際、このパイプライン全体によって、32の全クラスで非常に、非常に良い
527
00:29:50.325 --> 00:29:52.765
精度が得られました。
528
00:29:53.755 --> 00:29:55.085
また、ヒューマン・イン・ザ・ループもあります。
529
00:29:55.365 --> 00:29:57.525
なぜなら、私たちには政策専門家がいることを覚えていますよね、
530
00:29:57.865 --> 00:29:58.965
そして実際、彼らは、
531
00:29:59.475 --> 00:30:02.405
アルゴリズムの動作に本当に満足していました。
532
00:30:03.915 --> 00:30:05.695
私たちには、次のステップがあります。
533
00:30:05.975 --> 00:30:10.255
つまり、これら、このシステムは、MVPを作るためにも
534
00:30:10.255 --> 00:30:11.415
かなり短期間で作られました。
535
00:30:11.675 --> 00:30:13.295
そしてもちろん、これらの
536
00:30:13.295 --> 00:30:15.655
複雑さの一部は、
537
00:30:15.655 --> 00:30:19.735
BG and threeの独自バージョンをファインチューニングすることで回避できると思います。
538
00:30:21.755 --> 00:30:24.295
そしてもう一つは、ドメイン外検出が
539
00:30:24.295 --> 00:30:25.375
ないということです。
540
00:30:25.595 --> 00:30:28.695
つまり、もしテキストが、たとえば、
541
00:30:28.855 --> 00:30:32.255
料理のレシピについて話していても、私たちはそれを、ええと、
542
00:30:32.615 --> 00:30:34.015
政策として分類してしまいます。
543
00:30:34.475 --> 00:30:37.855
ただ良い点は、私たちが分類しようとするものはすべて
544
00:30:37.855 --> 00:30:39.215
政策だということです。
545
00:30:39.475 --> 00:30:41.535
なので、常に何らかの形でドメイン内にあります。
546
00:30:41.795 --> 00:30:45.175
ですから、これは、これは将来的に、
547
00:30:45.695 --> 00:30:47.015
あると良いものかもしれません。
548
00:30:49.095 --> 00:30:51.515
ええと、小さなデモをお見せします。
549
00:30:51.855 --> 00:30:56.475
ええと、これが最後のものです、ええと、この、この、
550
00:30:58.545 --> 00:31:01.085
放送、ええと、システムについては。
551
00:31:02.505 --> 00:31:05.695
ウィンドウを、ウィンドウを切り替える必要があります。
552
00:31:06.475 --> 00:31:08.695
ええと、できました。
553
00:31:11.055 --> 00:31:12.355
これはscreen scopeと呼ばれています。
554
00:31:13.815 --> 00:31:17.015
そして、
555
00:31:21.825 --> 00:31:25.005
はい、では、これが録画です。
556
00:31:25.065 --> 00:31:27.165
これは作成されました、ええと、基本的に
557
00:31:27.165 --> 00:31:31.805
この、ええと、3時間に及ぶスピーチの終了から40分後に、
558
00:31:32.225 --> 00:31:36.965
ええと、全体のパイプラインはすでに、
559
00:31:37.825 --> 00:31:39.805
ええと、この分類を作成していました。
560
00:31:40.305 --> 00:31:42.005
私たちはかなり、かなり多くのことをしています
561
00:31:42.005 --> 00:31:45.525
というのも、パートに分割し、私たちは、
562
00:31:45.585 --> 00:31:47.405
それが質問かどうかを理解し、
563
00:31:47.465 --> 00:31:49.445
フォローアップの回答があるかどうかも理解します。
564
00:31:50.225 --> 00:31:53.605
ただ、ええと、今日のウェビナーに関しては、私たちは
565
00:31:54.605 --> 00:31:57.245
実際に政策分野にタグ付けしています。
566
00:31:57.865 --> 00:32:01.325
なので、ええと、もし私が、ええと、彼が企業について話している
567
00:32:01.355 --> 00:32:05.245
それを選択すると、企業について話しているセグメントだけが
568
00:32:05.245 --> 00:32:06.925
表示されます。
569
00:32:07.305 --> 00:32:10.205
もちろん、全文検索もあります。
570
00:32:10.585 --> 00:32:15.125
要約もありますし、例えば他にあり得る
571
00:32:15.705 --> 00:32:19.205
ええと、このセグメント中に話している、話した
572
00:32:19.305 --> 00:32:20.325
トピックもあります。
573
00:32:21.025 --> 00:32:24.445
そして最後に、もちろん、そこには、そこには、
574
00:32:24.655 --> 00:32:29.005
どこかにチャットボットがあったはずで、たとえばその人に、ええと、
575
00:32:29.025 --> 00:32:31.125
何が、何があるのか尋ねることができます。
576
00:32:32.345 --> 00:32:35.315
委員としてのあなたの優先事項は?
577
00:32:37.545 --> 00:32:39.645
そしてここにも少し
578
00:32:39.875 --> 00:32:44.385
というのも、ええと、その、そのシステムは
579
00:32:44.945 --> 00:32:49.625
実際に、あー、質問に答える、
580
00:32:50.165 --> 00:32:53.385
あー、この質問に対して良い答えを出します。
581
00:32:53.485 --> 00:32:57.185
つまり、stemerman のヒアリング記録に基づくと、優先事項は
582
00:32:57.325 --> 00:32:58.745
なんとかかんとかです。
583
00:32:58.965 --> 00:33:03.025
でも実際には、私が言ったように、私たちは常に自分たちの、
584
00:33:03.405 --> 00:33:05.745
自分たちの回答を、何か現実のものに基づかせたいのです。
585
00:33:06.245 --> 00:33:08.865
なので、委員からの実際の引用も提示します。
586
00:33:09.525 --> 00:33:11.985
つまり基本的に、どんなステークホルダーでも
587
00:33:12.175 --> 00:33:15.065
知りたいと思っている人は、
588
00:33:15.065 --> 00:33:18.545
このビデオが80時間あったことを考えると、
589
00:33:19.285 --> 00:33:21.305
どんなステークホルダーでも知りたいと思っている人は、
590
00:33:21.615 --> 00:33:25.625
ある人物が特定のトピックについて何を言ったのかを
591
00:33:26.135 --> 00:33:27.225
ここに来るだけでわかります。
592
00:33:27.865 --> 00:33:31.305
実際、Google analytics を通じて、
593
00:33:31.535 --> 00:33:34.305
人々がこの部分を最も使っていることがわかります。
594
00:33:34.655 --> 00:33:39.345
なぜなら、これが本当にうまく答えられるからです、
595
00:33:40.325 --> 00:33:42.225
すべての具体的な質問に。
596
00:33:44.445 --> 00:33:48.335
ええと、以上です。
597
00:33:49.545 --> 00:33:52.235
いいですね。どうもありがとうございます。ありがとうございます。どうも
598
00:33:52.235 --> 00:33:53.235
ありがとうございます。
599
00:33:53.575 --> 00:33:57.555
あー、はい、チャットに質問が1つありました。うんうん。
600
00:33:57.775 --> 00:33:59.995
あー、それは、ここではどの LM を使っているのですか、というものです。
601
00:34:00.215 --> 00:34:03.475
あなたが言っているように、Gemini 1.5 のようなものですか?マルチモーダルですよね。
602
00:34:03.985 --> 00:34:06.315
はい、そうです。Gemini です。はい、
603
00:34:06.385 --> 00:34:07.385
Gemini なんですね。わかりました。
604
00:34:07.385 --> 00:34:11.235
では 1.5 ですか?はい。わかりました。はい。
605
00:34:11.295 --> 00:34:14.475
リリースされたばかりの 2.0 に移行する予定はありますか?
606
00:34:14.705 --> 00:34:15.915
はい、見ました。昨日でしたね。
607
00:34:16.305 --> 00:34:19.395
はい、今日は時間がありませんでした。それを見ました。
608
00:34:19.395 --> 00:34:22.155
すごいものですね。人々が UI に話しかけていて
609
00:34:24.415 --> 00:34:25.795
それで、はい。
610
00:34:25.795 --> 00:34:27.515
私の方からも1つあるかもしれません。
611
00:34:27.575 --> 00:34:30.675
つまり、例えば hybrid search で本当に大きな改善を
612
00:34:30.675 --> 00:34:32.155
見たことはありますか、あなたにとって、
613
00:34:32.155 --> 00:34:33.555
それを使うことで、例えば、
614
00:34:33.555 --> 00:34:35.435
劇的な改善でしたか?
615
00:34:35.625 --> 00:34:39.075
はい、完全にそうです。というのも、あー、私が言ったように、あー、
616
00:34:39.135 --> 00:34:42.515
vector だけの検索は、あー、この、非常に深く
617
00:34:43.075 --> 00:34:44.955
特化した、あー、言語では、あー、
618
00:34:45.255 --> 00:34:48.715
多次元空間内の点が近すぎるのです。
619
00:34:49.055 --> 00:34:51.235
つまり vectors が似すぎていて
620
00:34:51.495 --> 00:34:53.475
どういうわけかランダムな結果が出ます。
621
00:34:54.015 --> 00:34:55.795
そして同時に、ええと、
622
00:34:56.585 --> 00:35:00.235
sparse search だけでも適切な方法ではありませんでした。
623
00:35:00.495 --> 00:35:04.155
そしてこの種の hybrid search について、私たちはまた、いくつか、あー、
624
00:35:04.625 --> 00:35:07.315
grid search を、あー、
625
00:35:07.615 --> 00:35:09.955
どれだけ重みを与えるかというパラメータに対して行いました。うんうん。
626
00:35:10.035 --> 00:35:11.275
その2つのタイプに対してです。
627
00:35:11.615 --> 00:35:14.435
そして実際には、50 50 が最良だとわかりました。
628
00:35:15.025 --> 00:35:17.915
わかりました。情報としてだけですか?はい。
629
00:35:18.605 --> 00:35:20.415
わかりました。興味深いですね。ええと、はい、
630
00:35:20.415 --> 00:35:21.975
追加で質問があったんですが、忘れてしまいました。
631
00:35:21.975 --> 00:35:23.375
ああ、そうだ。Neo four J についてです。
632
00:35:23.755 --> 00:35:27.135
ええと、それはどういう感じで、たとえば graph rack と
633
00:35:27.135 --> 00:35:28.335
直接連携しているんですか、
634
00:35:28.435 --> 00:35:31.855
それとも、ええと、異なるシステムが連携して動いている
635
00:35:32.445 --> 00:35:34.695
ような感じですか。Neo 4G では、Neo 4G を使っているんですよね?
636
00:35:34.695 --> 00:35:35.975
それで、graph rack ベースのようなものですか、
637
00:35:36.035 --> 00:35:38.925
それとも主にエンティティで、その後ベクトル、という感じですか?はい。
638
00:35:39.065 --> 00:35:41.965
いえいえ、実際にはエンティティだけを扱っています。私たちはちょうど、
639
00:35:42.465 --> 00:35:44.645
ええと、今それを使い始めたところです。
640
00:35:44.755 --> 00:35:49.125
なるほど。私たちは、ええと、neo extract を使っています。
641
00:35:49.355 --> 00:35:52.085
それは LM の中にあるもので、ええと、
642
00:35:53.195 --> 00:35:56.645
構造化された出力を得ることに特化したオープンソースです。
643
00:35:57.185 --> 00:35:58.485
うんうん。まあ、
644
00:35:58.555 --> 00:36:02.685
もちろん問題は依然としてテキストからグラフへの変換だからです。
645
00:36:03.085 --> 00:36:06.965
つまり、はい、グラフからテキストにするのは、もうできています。
646
00:36:07.345 --> 00:36:09.285
でもテキストからグラフへの変換については、
647
00:36:09.285 --> 00:36:11.765
多くの人がそれについて話しているにもかかわらず、
648
00:36:12.325 --> 00:36:16.005
私はまだ汎用的な実装を見たことがありません。
649
00:36:16.005 --> 00:36:18.805
もちろんそれは、つまり、
650
00:36:19.075 --> 00:36:20.365
それについて汎用的な実装を持つのは
651
00:36:20.465 --> 00:36:22.285
本当に複雑だからです。
652
00:36:22.315 --> 00:36:23.315
はい。
653
00:36:23.675 --> 00:36:25.765
わかりました。いいですね。完璧です。ありがとうございます。
654
00:36:26.125 --> 00:36:27.485
私の質問は以上だったと思います。
655
00:36:28.065 --> 00:36:29.325
誰かが質問に答えるかどうか、
656
00:36:29.385 --> 00:36:30.965
少しだけ待ってみます。
657
00:36:31.955 --> 00:36:34.175
ええと、でも、そうでなければありがとうございました。
658
00:36:34.395 --> 00:36:35.535
そして皆さんにも、
659
00:36:35.755 --> 00:36:38.015
また参加できなかった方々にも、
660
00:36:38.015 --> 00:36:39.375
すべてオンラインで共有されます。
661
00:36:39.955 --> 00:36:41.775
ええと、すべて数日以内に YouTube で共有されます。
662
00:36:41.775 --> 00:36:43.575
編集担当に送ります。
663
00:36:44.075 --> 00:36:46.535
ええと、それで、そこでも視聴できるようになります。
664
00:36:47.115 --> 00:36:49.815
でも以上だと思います、sir。Sandra、本当にありがとうございました。
665
00:36:50.145 --> 00:36:51.535
プレゼンテーションをありがとうございました。
666
00:36:52.355 --> 00:36:54.135
それでは皆さん、また次回お会いしましょう。はい。
667
00:36:54.195 --> 00:36:55.735
バイバイ。バイバイ。