Join the Webinar
Loading...
何を学べますか？
このウェビナーでは、欧州委員会および欧州議会の法令に焦点を当て、大規模な文書コレクションを扱うために最適化された高性能ベクトルデータベースとしてのMilvusの活用について詳しく解説します。私たちのアプローチは、従来のRAGベースの分類からハイブリッド検索手法へと移行し、分類タスクに関連する上位文書を正確に特定するためにK-Nearest Neighbor (KNN)を活用します。このセッションは、大規模データセットにおけるベクトルベースのインデックス化とハイブリッド検索を活用して分類精度を向上させたい方に最適です。
取り上げるトピック：
- KNNとスパース検索の統合：KNN検索をスパース検索と組み合わせることで、分類ニーズに合致する上位文書を抽出する方法。
- 多言語・マルチドメイン用途に対応する多用途な埋め込み：BGE M3-Embeddingモデルは、複数の言語やドメインにわたって堅牢で高品質な埋め込みを提供するよう設計されており、多言語かつ部門横断的な環境における多様なタスクに適応できます。
- 実世界での応用：欧州の立法行為を用いたステップバイステップのデモンストレーションにより、KNN駆動の検索および分類ワークフローを紹介します。
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 バイバイ。バイバイ。
Meet the Speaker
Join the session for live Q&A with the speaker
Alessandro Saccoia
Co-Founder, Veridien.ai
Data-driven marketing and AI solutions expert. He has extensive experience in international companies like Nielsen Media and Vodafone, leading data science and product teams focused on applying machine learning to business challenges. Teaches AI and Data-Driven Marketing at the IULM University in Milan.